Emerging from rapid advances in digitization and technological capabilities is a new form of information systems development project: cyber projects. Cyber projects are complex, massive, and ambitious, often involving hundreds of academic, government, and industry professionals, requiring years of development, and costing millions of dollars. In our study, we examine how control is exercised in cyber projects. Based on a longitudinal study over eight years, we develop a process theory of the control of cyber projects. Initially we observe that project control is driven by the field, i.e., all of the individual or collective entities that subscribe to the general purpose of the project. This form of control is later replaced by a more bureaucratic form from government-sponsored entities to ensure that traditional project objectives are met. Once construction begins and the field understands the implications and promise of the project, we observe that control is again exerted by the primary project users in the field, complemented by authority-based control exerted by the government-sponsored entisty in the field.
Client control over the vendor has been identified as a critical factor in successfully managing information technology outsourcing relationships. Though prior studies have suggested that "how much" control is exercised has significant ramifications for individuals and firms, relatively few studies have operationalized and studied this important concept. In this study, we define the amount of formal control as the variety of mechanisms used by a client to exercise control over a vendor and the extent to which the mechanisms are used. We use literature on transaction cost economics and organizational control to build a model of the antecedents of the amount of formal control. The study uses data from 138 client-vendor matched pairs working in eight large, long-term, ongoing outsourcing arrangements to test specific hypotheses. The results suggest that clients who have technical or relationship management knowledge, or have high levels of trust in their vendors, use formal control mechanisms to a lesser extent. On the other hand, task uncertainty was found to be positively associated with the amount of formal control, and the degree of core competency involved in the outsourced activity was not found to be related to the amount of formal control. These results are discussed, and implications for research and practice are drawn.
Information technology (IT) adoption research recognizes theoretical limitations in discerning if and when user behavior results from perceived external influences or from personal volition. A clear understanding of this issue requires a precise distinction between mandatory and volitional behaviors. Consistent with organismic integration theory (OIT), this study situates the locus of user motivations inside the user. Drawing upon an endogenous view of behaviors, this research makes three key contributions. First, it develops the theoretical basis for clearly discerning if and when behavior results from perceived external influences or from personal volition. Specifically, it examines how endogenous psychological feelings of autonomy, freedom, conflict, and external pressure can predict and explain user intentions. Second, it proposes that behavior may result from combinations of perceived external influences and personal volition. Recognizing how such "collections of motivations" together influence behavior advances our understanding beyond the "dichotomy" of extrinsic versus intrinsic motivations often adopted in prior research. Third, it proposes that some desired behaviors may be thwarted or impeded by a conflict between perceived external influences and personal volition. The theoretically grounded research model was empirically validated in a field study on Blackboard, a Web-based education platform at a large university. Data collected from a sample of 211 users were tested using structural equation models of initial system adoption and experienced use. Empirical support was found for the proposed model and related hypotheses. The results of this study advance our understanding about user motivations for adopting IT.
Because of challenges often experienced when deploying software, many firms have embarked on software process improvement (SPI) initiatives. Critical to the success of these initiatives is the transfer of knowledge across individuals who occupy a range of roles in various organizational units involved in software production. Prior research suggests that a portfolio of different mechanisms, employed frequently, can be required for effective knowledge transfer. However, little research exists that examines under what situations differing portfolios of mechanisms are selected. Further, it is not clear how effective different portfolio designs are. In this study, we conceptualize knowledge transfer portfolios in terms of their composition (the types of mechanisms used) and their intensity (the frequency with which the mechanisms are utilized). We hypothesize the influence of organizational design decisions on the composition and intensity of knowledge transfer portfolios for SPI. We then posit how the composition and intensity of knowledge transfer portfolios affect performance improvement. Our findings indicate that a more intense portfolio of knowledge transfer mechanisms is used when the source and recipient are proximate, when they are in a hierarchical relationship, or when they work in different units. Further, a source and recipient select direction-based portfolios when they are farther apart, in a hierarchical relationship, or work in different units. In terms of performance, our results reveal that the fit between the composition and intensity of the knowledge transfer portfolio influences the recipient's performance improvement. At lower levels of intensity direction-based portfolios are more effective, while at higher levels of intensity routine-based portfolios yield the highest performance improvement. We discuss the implications of our findings for researchers and for managers who want to promote knowledge transfer to improve software processes in their organizations.
Enterprise resource planning (ERP) systems and other complex information systems represent critical organizational resources. For such systems, firms typically use consultants to aid in the implementation process. Client firms expect consultants to transfer their implementation knowledge to their employees so that they can contribute to successful implementations and learn to maintain the systems independent of the consultants. This study examines the antecedents of knowledge transfer in the context of such an interfirm complex information systems implementation environment. Drawing from the knowledge transfer, information systems, and communication literatures, an integrated theoretical model is developed that posits that knowledge transfer is influenced by knowledge-related, motivational, and communication-related factors. Data were collected from consultant-and-client matched-pair samples from 96 ERP implementation projects. Unlike most prior studies, a behavioral measure of knowledge transfer that incorporates the application of knowledge was used. The analysis suggests that all three groups of factors influence knowledge transfer, and provides support for 9 of the 13 hypotheses. The analysis also confirms two mediating relationships. These results (1) adapt prior research, primarily done in non-IS contexts, to the ERP implementation context, (2) enhance prior findings by confirming the significance of an antecedent that has previously shown mixed results, and (3) incorporate new IS-related constructs and measures in developing an integrated model that should be broadly applicable to the interfirm IS implementation context and other IS situations. Managerial and research implications are discussed.
In today's competitive environment, an increasing number of firms are building common information systems, which will be deployed globally, to support their strategic globalization initiatives. These systems are designed to meet the requirements of a diverse set of stakeholders with different business needs, priorities, and objectives. One managerial tool for addressing and reconciling such differences is control, which encompasses all attempts to motivate individuals to act in a manner that is consistent with organizational objectives. This paper examines two research questions. How do stakeholders exercise control during different phases of large IS projects? Why do control choices change across project phases? Results of two case studies suggest control is exercised differently for each phase. During the initial phase of a project, control is exercised as "collective sensemaking," in which both IS and business stakeholders utilize mostly informal mechanisms of control. During development, "technical winnowing" of mechanisms occurs such that control is vested primarily in IS managers, who structure hierarchical relationships with subordinates and who rely extensively on formal control mechanisms. Both IS and business stakeholders employ formal and informal mechanisms during implementation to exercise control as "collaborative coordinating." The results also suggest that changes in control choices from one project phase to another are triggered by factors in the project, stakeholder, and global contexts. As factors change across phases, so too do control choices. Further, problems that surface in one project phase trigger changes to controls in subsequent phases. These findings are integrated into a model of the dynamics of control. Implications of these results are drawn, and directions for future research are suggested.
In spite of the attention it has received, there is still much that is not understood about the management of systems development efforts. This research examines one aspect of the management process: the function of control. In this paper, control is viewed broadly, encompassing all attempts to ensure individuals in organizations act in a maimer that is consistent with meeting organizational goals and objectives. Control is categorized into formal modes (behavioral, outcome) and informal modes (clan, self). Formal and informal control modes are implemented via a variety of mechanisms, such as linking pay with performance, socialization, and team-building. Relatively little is known about the modes of control used to manage information systems development efforts. The objective of this research is to address this lack of understanding in the literature by exploring how control modes are implemented during systems development projects and by investigating why IS and user stakeholders implement particular combinations of control modes. To meet this objective, a series of four case studies of systems development projects was conducted. The results reveal that users, as well as IS managers, play a critical role in controlling systems development projects. Moreover, the results suggest that all stakeholders implement a portfolio of control modes that typically includes both formal and informal modes. This portfolio contains a mix of overlapping and redundant mechanisms used to exercise these modes of control. The results also suggest that constructing a portfolio of control modes is a process that includes selecting appropriate preexisting mechanisms of formal control; designing new mechanisms with which to implement formal control, if necessary; and supplementing the mechanisms of formal control with mechanisms of informal control. Throughout this process of construction, the choice of particular control mechanisms depends on task characteristics, role expectations, and project-related knowledge and skills.
In spite of strong conceptual arguments for the value of strategic data planning as a means to increase data integration in large organizations, empirical research has found more evidence of problems than of success. In this paper, four detailed case studies of SDP efforts, along with summaries of five previously reported efforts, are analyzed. Fifteen specific propositions are offered, with two overall conclusions. The first conclusion is that SDP, though conceived of as a generally appropriate method, may not be the best planning approach in all situations. The second conclusion is that the SDP method of analyzing business functions and their data requirements may not be the best way to develop a "data architecture," given the required level of commitment of talented individuals, the cost, the potential errors, and the high level of abstraction of the result. These lessons can aid practitioners in deciding when to use SDP and guide them as they begin the process of rethinking and modifying the SDP to be more effective.